Adaptive Fault Tolerant Systems: Reflective Design and Validation

Reflection has been used with some success, since quite a few years now, for dealing with separation of concerns and transparency of fault-tolerance mechanisms for the application. Nevertheless, it has also shown some concerning the control of fine-grain information such as thread control or other deep aspects of the platform. We propose here the use of a new concept, called multi-level reflection, for firstly solving these issues, but also for introducing more adaptation into fault-tolerant reflective architectures. We also discuss some essential validation issues of reflective systems, which are still a challenge for future research. 1. Problem statement Flexibility, reuse, and adaptation are becoming key aspects of today's large embedded systems (satellite systems, transport, automotive), and explain the increasing use of off-the-shelf components in the concerned industries. This trend raises challenges when considering the dependability of the resulting systems: How can we build dependable systems from components that don't specifically target dependability concerns? For these reasons, integrators are looking for sound and principled approaches that help them separate functional development from fault-tolerance concerns, within large projects, over long life-time. Computational Reflection, an architectural paradigm that appeared in the late eighties, and related technologies such as aspect oriented programming, appear as very promising and powerful approaches to tackle this issue. Reflective architectures are centered on a key element, their meta-model, that insures the separation of concerns between the "base" system (here the system resulting from component integration) and the mechanisms (in our case, fault-tolerance) that are added to the base system. To be effective, this meta-model must take into account both the multi-component nature of the systems and the requirements of fault-tolerance that it should help implement. Within this work, we address this dual issue and propose a methodology to help design meta-models that specifically target the implementation of faulttolerance into systems made of third party components. To some extent, we also address validation issues. 2. An introduction to multi-level reflection A reflective system is basically structured around a representation of itself (its self-representation or metamodel) that is causally connected to the real system [1]. This meta-model divides the system into two distinct parts: a base-level where normal computation takes place, and a meta-level where the system computes about itself (meta-computation or meta-level software). The design of a reflective system mainly consists in providing reflective mechanisms to establish metamodels. The reflective mechanisms provide observation and control features that can be divided into four classes: • reification mechanisms by which the base-level exhibits information about its own computation; • introspection mechanisms by which the meta-level can obtain (on-demand) structural information about the base-level; • behavioral intercession leading the meta-level to control base-level computation; • structural intercession enabling the meta-level to update base-level entities. This kind of mechanisms is the corner stone of any reflective system or component. In object-oriented system, this is often provided by a so-called meta-object protocol (MOP), for which base-level entities are objects and meta-level entities are metaobjects. In a reflective object-oriented application meta-objects populate the meta-level and use the meta-model to control the behavior of normal application objects (i.e. basedlevel object). The meta-model is structured around notions that are "constitutive" of the base level; i.e. these notions are common to all applications that share the same programming model. The systems we are interested in are made of thirdparty components that are most often organized in a layered architecture: OS kernel, system libraries, compilers, virtual machines, middleware, etc. These